• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    For a simple, fast and reliable checking of the function and the execution of an automation task in the form of software in a multi-channel safety-related automation component (1), the software (SW1) in a channel (Kl) of the automation component (1) in an active part (P1 ) of the hardware of the channel (K1) is executed and executed in this channel (K1) in a verification unit (V1) to the software (SW1) first diversified software (SW3), wherein in a processing step (ZI) of the software (SW1) associated Input data (E2) and with the software (SW1) in this processing step (Z1) calculated first output data (A2) in a memory unit (M1) are cached and the diverse software (SW3) in the verification unit (V1) from the stored input data (E2 ) is calculated independently of the processing of the software (SW1) in the active part (P1) second output data (A2) and to check the Abar the second output data (A2) calculated using the diversified software (SW3) is compared with the stored first output data (A2) of the software (SW1).
    公开号:AT515341A1
    申请号:T50043/2014
    申请日:2014-01-23
    公开日:2015-08-15
    发明作者:Franz Kaufleitner；Alois Holzleitner
    申请人:Bernecker & Rainer Ind Elektronik Gmbh；
    IPC主号:
    专利说明:

    Procedure for checking the execution of software
    The subject invention relates to a method for checking the execution of an automation task in the form of software in a multi-channel safety-related automation component.
    In order that electronic automation components, such as e.g. Control units, actuators, sensors, etc., may be used for personal protection tasks, must meet these special requirements. Essential aspects of these requirements is to make the automation components so robust that, if errors occur in the automation component, there can be no danger to persons in the environment of the automation component. To meet this requirement, such electronic automation components are usually equipped with a diagnostic function. This diagnostic function has the task of detecting possible errors in the active part of the automation component and deactivating the parts of the automation component affected by the error, or triggering another safety-related action. In this case, an active part is understood to be a component which processes data, carries out calculations, etc., that is to say typically processors, arithmetic units, programmable logic controllers, etc. In order that the required security levels, e.g. a SIL (safety integrity level) according to the IEC 61508 or other standards, safety-related functions in an automation component are usually also implemented as multi-channel. A safety-relevant function is present multiple times and a calculation of the function is only considered valid if all channels provide the same result. For safety-related automation systems or automation components, so-called Failure Mode and Effects Analysis (FMEA) are carried out as part of the development. These are well-known analytical methods to find potential weaknesses, with the aim of avoiding errors and increasing technical reliability.
    The diagnostic function in an automation component is usually designed so that possible, e.g. As part of the system designed to be diagnosed in an FMEA, errors are diagnosed and detected. The diagnostic routines are statically implemented in the automation component in their own diagnostic processors and do not adapt very or very little to the application-specific environment in the active part of the automation component. If complex electronic components, such as processors, are used in the automation component, extensive and complex diagnostic functions, such as eg, Opcode tests and register tests, necessary. With increasing complexity of the processor used and / or the software running on it, it becomes increasingly difficult to correctly implement the diagnosis in the automation component. Apart from that, the diagnosis can not be implemented for all possible applications of an automation component, with which the diagnosis can not give one hundred percent certainty.
    Therefore, the channels of a safety-related, multi-channel automation component are diversified, either with diversified hardware or diverse software. In the technical context, diversity means that a system or function is redundant, but deliberately uses different implementations of the system or function. Here, consequently, the different channels of the multi-channel automation component are executed differently, ie with different hardware or different software. An automation task in the automation component is therefore carried out with different hardware or different software, whereby in the error-free case, the different implementations of the automation task must deliver the same results.
    If diverse hardware (see FIG. 1) is used, then processors with different processor cores must be used in the various channels. However, the current trend in the processor manufacturers is going in a completely different direction, namely in the direction of focusing on as few different processor cores. Many manufacturers of embedded processors, such as those used in automation components, frequently use so-called ARM (Advanced RISC Machines) cores in their products, so that hardware diversity is only possible through the use of "exotic" processors. Of course, "exotic" processors have no distribution and thus no appreciable operational reliability, which is also an important aspect for applications in safety-related automation components in personal protection. For safety-related automation components, the trend is therefore towards homogeneous hardware.
    An alternative approach is therefore to diversify the software (see Fig.2). In this case, errors in the processor core or in the memory can be detected with sufficiently high probability. However, diversity software has the disadvantage that the running time of the different channels can differ greatly. However, the performance of the automation components of a multi-channel system is determined by the slowest channel because the result obtained is valid only after comparing the data of all channels.
    It is therefore an object of the present invention to provide a method for simple, fast and reliable checking of the function and the execution of an automation task in a multi-channel safety-related automation component which does not have the abovementioned disadvantages.
    This object is achieved according to the invention in that the software is executed in a channel of the automation component in an active part of the channel's hardware and in this channel a software that is the first to perform diverse software is executed in a processing step, the input data associated with the software being in a processing step calculated with the software in this processing step first output data in a memory unit and the diverse software in the verification unit from the stored input data independent of the processing of the software in the active part second output data calculated and to check the processing of the calculated with the diverse software second output data be compared with the stored first output data of the software.
    In this way, the verification of the execution of the software in the active part of a channel can be decoupled from the diversified software. The execution of the software in the active part, so the implementation of the actual automation task is not hindered, whereby the performance of the automation component depends essentially on the execution of the software in the active part, but not by the review by the diverse software. This makes it possible to implement an automation component with multi-purpose software, but which is not subject to performance losses as in the prior art. For this purpose, it is irrelevant whether the hardware is diverse or homogeneous.
    If the review of the software by the diverse software is after an nth processing step of the software, where n is an integer positive number greater than one, then the diversified software may also be slower than the software in the active part of the channel. This makes it possible, in particular, to use diversified software created by coded processing, which as a rule runs orders of magnitude slower than the software to be checked. Likewise, this allows the diverse software to run on a verification unit that operates slower than the active part of the channel.
    Particularly advantageously, the checking unit is implemented in a diagnostic part in which, in addition to the diversified software, diagnostic functions are also carried out as diagnostic software. This means that existing hardware in the channel can be used simultaneously to carry out the check.
    Preferably, the software is additionally checked in a second channel or in all channels of the multi-channel safety-related automation component, which further increases the security of the automation component.
    The security of the automation component can be increased if, in two channels of the multichannel safety-related automation component, output data is calculated in each execution step of the software, which are compared with one another after the processing step.
    The subject invention will be explained in more detail below with reference to Figures 1 to 3, which show by way of example, schematically and not by way of limitation advantageous embodiments of the invention. It shows
    1 shows a safety-related automation component according to the prior art,
    2 shows a safety-related automation component according to the state of the art with diverse software,
    3 shows a safety-related automation component according to the invention with checking the execution of an automation task.
    1 shows a safety-related automation component 1 according to the prior art. Therein two channels K1, K2 are implemented. Each channel K1, K2 comprises an active part P1, P2 and a diagnostic part D1, D2. An active part P1, P2 is, for example, a processor, a programmable logic circuit (e.g., a FPGA (Field Programmable Gate Array)), or similar component that can process data or perform calculations. The active part P1, P2 carries out an automation task implemented thereon, e.g. a data manipulation, a calculation, etc., from. The diagnostic part D1, D2 is a programmable component, e.g. as a processor, executed on the diagnostic functions for detecting and handling errors in the active part P1, P2 as software. The diagnosis part D1, D2 therefore checks the function of the active components P1, P2 and, if errors are detected, e.g. by deactivating certain functions of the active components P1, P2 or by transferring the automation component 1 into a safe state, possibly in conjunction with the issuing of an error message, e.g. to a higher-level controller. Each channel K1, K2 calculates from input data E, e.g. Control data or measured quantities, an output quantity A1, A2, which are stored in a comparison unit 2, e.g. a separate comparison unit or one of the active parts P1, P2, and if equal, as valid output data A, e.g. Control variables, calculation results, etc., are output. The hardware, that is, the active parts P1, P2, can be made diversified or the same.
    FIG. 2 shows the example according to FIG. 1 with diverse software in the active parts P1, P2. The software SW1 in the active part P1 of the first channel K1 is faster here than the software SW2 in the active part of the second channel K2. That that the software SW1 of the first channel K1, e.g. upon execution of a particular automation task, procedure or function, typically software SW2 of the second channel K2, e.g. when processing the same automation task, procedure or function, must wait (indicated by the dashed double arrows), because after each processing, the results of the processing, e.g. the output data A1, A2, must be compared.
    The slower software, here SW2, determines the speed of the automation component. In the embodiment shown here, the check is carried out e.g. after a complete code cycle of software SW1, SW2.
    3 shows an inventive implementation of a multi-channel safety-related automation component 1. A channel K1, K2 in this case again comprises an active part P1, P2 and a diagnostic part D1, D2. In the diagnostic parts D1, D2 again certain diagnostic functions for the associated active parts P1, P2 are programmed. The hardware of the active parts P1, P2 is homogeneous here, and in both active parts P1, P2 the same software SW1 runs here, i. that the same software SW1 is running in both channels K1, K2 on the same active parts P1, P2.
    Instead of the software SW1 but could be implemented in the active part P2 of the second channel K2 also running to the first channel K1 software SW1 diverse software SW2, such. described in Figure 2, without departing from the spirit. Likewise, the active part P2 in the second channel K2 could be implemented as diverse hardware.
    In a checking unit V1, e.g. the diagnosis part D1, in the first channel K1, a software SW3 diversified to the software SW1 in the active part P1 is now implemented and executed. The processing of the diversified software SW3 in the checking unit V1 is temporally decoupled from the processing of the software SW1 in the active part P1 and thus in the processing time independent of the execution of the software SW1 in active part P1. The software SW1 in the active part P1 can therefore be e.g. be a real-time application, while the diverse software SW3 in the verification unit V1 has a different, usually slower, runtime. Nevertheless, the diversified software SW3 is used in the checking unit V1 to check the execution of the software SW1 in the active part P1. However, with a slower diversified software SW3, this can only take place in every nth, with the positive integer n> 1, execution step Z1 of the software SW1. For this purpose, the current for a processing step Z1 of the software SW1 input data Ez in the first channel K1 and the calculated from the software SW1 in the active part P1 of the first channel K1 output data Az are cached in a memory unit M1. The diversified software SW3 in the checking unit V1 reads out these stored input data Ez and output data Az from the memory unit M1. From the read-out input data Ev, the diversified software SW3 likewise calculates output data Az ', which in the error-free case must be equal to the stored output data Az of the software SW1 in the active part P1. The calculation of the output data Az 'by the diversified software SW3 may take longer than the calculation of the output data Az in the active part P1. For example, the calculation in the checking unit V1 may also be slower by a factor of 100 to 1000 than in the active part P1. If the output data Az and Az 'compared in the verifying unit V1 are not equal, there is an error and the verifying unit V1 sets a corresponding action, e.g. Transfer the automation component 1 to a safe state, issue an error message or trigger another safety-related action. After completion of the check by the software SW3 in the checking unit V1, the next check of the current processing step Z1 can start, wherein intermediate input data Ez and output data Az calculated therefrom with the software SW1 need not be stored in the memory unit M1.
    If U is processing time for a processing step Z1 of the software SW1 in the active part P1 and t2 is the processing time for a processing step Z3 of the diversified software SW3 in the checking unit V1, then n x t-i > t2.
    If a checking unit V1, V2 is implemented in a diagnosis part D1, D2, then the diversified software SW3 can additionally run in addition to the diagnostic functions implemented in the diagnosis part D1, D2 as diagnostic software, as indicated in FIG.
    The same check can be made in parallel in the second channel K2, and every other channel, between the software SW1, or SW2 in the case of diversified software in the active parts P1, P2, and the diversified software SW3 in the second channel P2 verification unit V2.
    The processing of the software SW1 in the active parts P1, P2 of the channels K1, K2 is therefore not braked by the review by diverse software SW3 in the verification unit V1, V2. In the two channels, a check of the execution of the software SW1 in the active parts P1, P2 of the two channels K1, K2 takes place for every nth processing step of the software SW1.
    In addition, in each execution step of the software SW1 in the first channel K1, the output data A1 generated thereby can be compared with the output data A2 generated in the second channel K2 in this processing step in a comparison unit 2, which makes the
    Degree of verification increased to error. In the case of diverse hardware in the two channels, delays may occur due to different run times in the different active parts P1, P2, but these are not caused by the diversified software.
    The review of the execution of the software SW1 in the automation component 1 is thus carried out by a time-decoupled diversified software SW3, which is implemented for example in a diagnostic part D1, D2 and can monitor and check every nth processing step of the software SW1. In addition, the output data A1, A2 of two channels K1, K2 generated by the software SW1 can be compared as before in each processing step of the software SW1. The inherently worse runtime behavior of diversified software can thus be compensated by the invention. Moreover, it is irrelevant whether the hardware is diversified or not.
    As a processing step Z, a completed arithmetic operation in an active part P1, P2 is generally considered by the software SW1, SW2 running therein, e.g. a mathematical calculation by the software SW1, SW2, the execution of a function or procedure of the software SW1, SW2, the processing of input data according to a predetermined scheme, a complete code cycle of the software SW1, SW2, etc. For example, the active part P1 of a first channel K1 may be a processor with the support of a floating-point unit FPU and the software SW1 running on it mathematical code. However, the associated diagnosis part D1 is e.g. just a simpler processor that only has a floating point library or a processor that does not use the FPU. Nevertheless, it is possible with the invention, for example, to check the high-performance FPU in the active part P1 by a low-performance floating point library in the diagnostic part D1.
    By means of known methods of so-called coded processing, it is possible to produce, as it were, automated diverse software SW3 to a predetermined software SW1. The generated diversified software SW3 is usually a factor of at least 100 slower than the original software. By means of the invention, diversified software SW3 generated by coded processing can now also be used, which can considerably reduce the expenditure for generating the diversified software SW3.
    Although the description has been described with respect to a dual-channel safety-related automation component 1, the invention can of course be applied analogously to an automation component 1 having more than two channels.
    权利要求:
    Claims (6)
    [1]
    1. A method for checking the execution of an automation task in the form of software (SW1) in a multi-channel safety-related automation component (1), characterized in that the software (SW1) in a channel (K1) of the automation component (1) in an active part (P1) of the hardware of the channel (K1) is executed and in this channel (K1) in a checking unit (V1) to the software (SW1) first diverse software (SW3) is executed, wherein in a processing step (Z1) of the software ( SW1) associated input data (Ez) and with the software (SW1) in this processing step (Z1) first output data (Az) in a memory unit (M1) are cached and the diverse software (SW3) in the verification unit (V1) from the stored Input data (Ez) is calculated independently of the processing of the software (SW1) in the active part (P1) second output data (Az ') and for checking During execution, the second output data (Az ') calculated with the diversified software (SW3) are compared with the stored first output data (Az) of the software (SW1).
    [2]
    2. The method according to claim 1, characterized in that the verification of the software (SW1) by the diversified software (SW3) after an n-th processing step (Z1) of the software (SW1), where n is a positive integer greater than one ,
    [3]
    3. The method according to claim 1 or 2, characterized in that the checking unit (V1) in a diagnostic part (D1) is implemented in which in addition to the diverse software (SW3) also diagnostic functions are performed as diagnostic software.
    [4]
    4. The method according to any one of claims 1 to 3, characterized in that the verification of the software (SW1) additionally in a second channel (K2) or in all channels of the multi-channel safety-related automation component (1) is performed.
    [5]
    5. The method according to claim 4, characterized in that in at least one further channel (K2) of the multi-channel safety-related automation component (1) instead of the software (SW1) to a diversified second software (SW2) is executed.
    [6]
    6. The method according to any one of claims 1 to 5, characterized in that in two channels (K1, K2) of the multi-channel safety-related automation component (1) in a processing step (Z1) of the software (SW1), or the second software diversified (SW2 ), respectively output data (Az) are calculated, which are compared with each other after the processing step (Z1).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP0742505A2|1996-11-13|Safety-oriented monitoring device for a machine
    EP2422244B1|2013-11-27|Safety-related control unit, and method for controlling an automated system
    EP2513796B1|2013-10-02|Method for operating a processor
    DE102013203358A1|2013-09-19|Method for verifying integrity of sensitive vehicle control system, involves taking remedial action when fault is detected and resetting operation control module when fault is detected and remedial action is not taken
    DE102007054672A1|2009-05-20|Field device for determining or monitoring a process variable in process automation
    EP2902905B1|2016-03-30|Method for checking the processing of software
    EP2447843B1|2013-07-03|Method for verifying an application program of an error-free memory-programmable control device and memory-programmable control device for carrying out the method
    DE102004046611A1|2006-03-30|Method for processing a computer program on a computer system
    EP3001313A1|2016-03-30|Methods for simulating an application program of an electronic control device on a computer
    EP1701230A1|2006-09-13|Diagnosis of parallel-connected redundant signal output channels
    DE102009050161A1|2011-04-28|A method and apparatus for testing a system having at least a plurality of parallel executable software units
    DE102008043374A1|2010-05-06|Device and method for generating redundant but different machine codes from a source code for verification for a safety-critical system
    EP3709166B1|2021-12-15|Method and system for secure signal manipulation for testing integrated security functionalities
    DE102007015369A1|2008-07-03|Critical functions logical program flow monitoring method for use in measuring device of automation and processing control technique, involves storing actually lying identification symbols as predecessor signature for monitoring cycle
    EP3311273A1|2018-04-25|Method and apparatus for protecting a program counter structure of a processor system and for monitoring the handling of an interrupt request
    DE112013006981T5|2016-04-07|Control system test equipment
    DE102016214117A1|2018-02-01|Determining an execution time of a user program
    EP2864845B1|2016-09-07|Automated reconfiguration of a discrete event control loop
    EP3486825A1|2019-05-22|Method and apparatus for the computer-aided determination of a severity of a breach in integrity
    DE102017201032A1|2018-05-03|Redundant processor architecture
    EP3173928A1|2017-05-31|Method and device for checking a component error tree
    EP3388944A1|2018-10-17|Method for error detection within an operating system
    DE102009002734A1|2010-11-11|Field device for determining or monitoring process variable in process automation, has sensor, which works according to defined measuring principle, and control or evaluation unit, which processes and evaluates measured data
    DE102015223115A1|2017-05-24|Criticality analysis for ECUs
    DE102014118716A1|2016-06-16|Method for operating a technical arrangement
    同族专利:
    公开号 | 公开日
    US20150205698A1|2015-07-23|
    EP2902905A1|2015-08-05|
    EP2902905B1|2016-03-30|
    US9703672B2|2017-07-11|
    AT515341B1|2015-12-15|
    CA2874995A1|2015-07-23|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP0910018A2|1997-10-15|1999-04-21|Alcatel|Error checking method for real-time system software|
    EP1316884A2|2001-11-28|2003-06-04|Siemens Aktiengesellschaft|Method for the generation and/or execution of a diversified program flow|
    DE10212151A1|2002-03-19|2004-01-08|Rainer Faller|Process, computer program product, computer program, storage medium with computer program stored thereon and computer system for safety-critical applications in machines, devices and / or systems|
    US4622667A|1984-11-27|1986-11-11|Sperry Corporation|Digital fail operational automatic flight control system utilizing redundant dissimilar data processing|
    US6199171B1|1998-06-26|2001-03-06|International Business Machines Corporation|Time-lag duplexing techniques|
    US7353365B2|2004-09-29|2008-04-01|Intel Corporation|Implementing check instructions in each thread within a redundant multithreading environments|
    US20060200278A1|2005-03-02|2006-09-07|Honeywell International Inc.|Generic software fault mitigation|
    US7987385B2|2007-07-24|2011-07-26|Ge Aviation Systems Llc|Method for high integrity and high availability computer processing|
    DE502007003475D1|2007-08-22|2010-05-27|Siemens Ag|Operating method for a control device of a safety-related automation device for checking the reliability of an automation system|
    DE102009054637A1|2009-12-15|2011-06-16|Robert Bosch Gmbh|Method for operating a computing unit|
    WO2011101707A1|2010-02-16|2011-08-25|Freescale Semiconductor, Inc.|Data processing method, data processor and apparatus including a data processor|
    US8499193B2|2010-07-30|2013-07-30|Honeywell International Inc.|Integrated dissimilar high integrity processing|
    DE102011053580A1|2011-09-14|2013-03-14|Zf Lenksysteme Gmbh|METHOD FOR OPERATING AN ELECTRIC AUXILIARY POWER STEERING|
    US9118351B2|2012-02-15|2015-08-25|Infineon Technologies Ag|System and method for signature-based redundancy comparison|CN106774111B|2016-11-28|2019-12-13|北京龙鼎源科技股份有限公司|task processing method and device in PLC system and PLC system|
    JP2018101241A|2016-12-20|2018-06-28|株式会社日立製作所|Processing device|
    US10275329B2|2017-02-09|2019-04-30|Red Hat, Inc.|Fault isolation and identification in versioned microservices|
    法律状态:
    2018-03-15| HC| Change of the firm name or firm address|Owner name: B&R INDUSTRIAL AUTOMATION GMBH, AT Effective date: 20180205 |
    优先权:
    申请号 | 申请日 | 专利标题
    ATA50043/2014A|AT515341B1|2014-01-23|2014-01-23|Procedure for checking the execution of software|ATA50043/2014A| AT515341B1|2014-01-23|2014-01-23|Procedure for checking the execution of software|
    EP14192756.6A| EP2902905B1|2014-01-23|2014-11-12|Method for checking the processing of software|
    CA2874995A| CA2874995A1|2014-01-23|2014-12-16|Method for verifying the processing of software|
    US14/601,289| US9703672B2|2014-01-23|2015-01-21|Method for verifying the processing of software|
    [返回顶部]